Re: NIS
der Mouse (mouse@Collatz.McRCIM.McGill.EDU)
Tue, 18 Apr 1995 15:12:52 -0400
> Assuming that the followers of this thread are not going to act on
> the obvious conclusion and switch to kerberos or some-such,
The kerberos implementation is not exportable, and I've never heard of
an exportable spec being available and thus code potentially
redeveloped somewhere in the civilized part of the world. Perhaps I've
just not listened to the right places.
> So now the problem lies in the difficulty of replacing the
> authentication mechanism on traditional systems, and the subsystems
> built up around these. Remember for instance that login can also
> deal with password aging. On traditional UNIX systems passwords are
> wanted by
> 'su' 'login' 'xdm' 'ftp' 'Pc-NFS' 'kashare' 'ftam' 'popper'
> '(yp)passwd' 'chsh' 'chfn' `yppasswdd' ...
Almost all of these just want to verify passwords. Only a couple
(passwd, yppasswd) care in any way about the details of the hash; the
rest just care about strcmp(foo->pw_passwd,crypt(pw,foo->pw_passwd)).
> While the password file/map is perused by many programs (eg ls)
Most of them don't give a hoot about passwords, and would be perfectly
content if pw->pw_passwd didn't even exist.
> Getpw*(3) returning a longer password string is probably not a
> problem as the password structure contains char *pw_passwd, rather
> than a fixed string. Getpass (in the BSD sources) allows a 128 char
> pass phrase, unfortunately SunOS gently truncates to 8 characters,
crypt(3) is largely responsible; it inflicts this on its argument...at
least in traditional implementations that do the DES thing.
> Crypt(3) is of course the thing you really want to modify to get your
> new hash.
> Then all you have to worry about is the set of programs which "know"
> the size of crypt(3)'s output, and whether the programs mentioned
> above (and any others you think of) strcpy that crypt-string
> anywhere.
NetBSD (which I am peripherally involved with) has a crypt() that
already breaks the 13-character assumption, so such programs will have
been identified and dealt with already, at least in that distribution.
I implemented a replacement crypt() based on MD5, which works fine as
far as I can tell. Here are a couple of passwd entries (each one
tweaked slightly; don't bother trying to crack them):
mouse:=1.64.l2eerGWzTb.WTRwSLRkV81rvr9y5tpafY/qYGW.2Off.:0:0::0:0:der Mouse:/homedir/mouse:/local/mouse/bin/mcsh
steve:oszIFpJdAf4pw:1096:10::0:0:Steve Larchman:/homedir/steve:/local/gnu/bin/bash
Note that (if you have DES-based crypt code available) it understands
old hashed passwords, so if you really want to just copy a hashed
password, you can.
Of course, as you point out, this depends on programs being prepared
for (in this case) a 50-character hashed password.
der Mouse
mouse@collatz.mcrcim.mcgill.edu